home *** CD-ROM | disk | FTP | other *** search
- Xref: bloom-picayune.mit.edu comp.lang.lisp:8750 news.answers:4560
- Path: bloom-picayune.mit.edu!enterpoop.mit.edu!spool.mu.edu!uunet!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!mkant
- From: mkant+@cs.cmu.edu (Mark Kantrowitz)
- Newsgroups: comp.lang.lisp,news.answers
- Subject: FAQ: Lisp Frequently Asked Questions 2/6 [Monthly posting]
- Summary: Frequently asked questions about Lisp -- General Questions
- Message-ID: <lisp-faq-2.text_724237288@cs.cmu.edu>
- Date: 13 Dec 92 09:01:37 GMT
- Article-I.D.: cs.lisp-faq-2.text_724237288
- Expires: Tue, 26 Jan 1993 09:01:28 GMT
- Sender: news@cs.cmu.edu (Usenet News System)
- Reply-To: lisp-faq@think.com
- Followup-To: poster
- Organization: School of Computer Science, Carnegie Mellon
- Lines: 546
- Approved: news-answers-request@MIT.Edu
- Supersedes: <lisp-faq-2.text_721645310@cs.cmu.edu>
- Nntp-Posting-Host: a.gp.cs.cmu.edu
-
- Archive-name: lisp-faq/part2
- Last-Modified: Thu Nov 5 19:30:40 1992 by Mark Kantrowitz
- Version: 1.27
-
- ;;; ****************************************************************
- ;;; Answers to Frequently Asked Questions about Lisp ***************
- ;;; ****************************************************************
- ;;; Written by Mark Kantrowitz and Barry Margolin
- ;;; lisp-faq-2.text -- 28371 bytes
-
- This post contains Part 2 of the Lisp FAQ.
-
- If you think of questions that are appropriate for this FAQ, or would
- like to improve an answer, please send email to us at lisp-faq@think.com.
-
- Topics Covered (Part 2):
-
- [2-1] Is there a GNU-Emacs interface to Lisp?
- [2-3] What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
- [2-4] Is Lisp inherently slower than more conventional languages such as C?
- [2-5] Why does Common Lisp have "#'"?
- [2-6] How do I call non-Lisp functions from Lisp?
- [2-7] Can I call Lisp functions from other languages?
- [2-8] I want to call a function in a package that might not exist at
- compile time. How do I do this?
- [2-9] What is CDR-coding?
- [2-10] What is garbage collection?
- [2-11] How do I save an executable image of my loaded Lisp system?
- How do I run a Unix command in my Lisp?
- How do I get the current directory name from within a Lisp program?
- [2-12] I'm porting some code from a Symbolics Lisp machine to some
- other platform, and there are strange characters in the code.
- What do they mean?
- [2-13] History: Where did Lisp come from?
- [2-14] How do I find the argument list of a function?
- How do I get the function name from a function object?
- [2-15] How can I have two Lisp processes communicate via unix sockets?
-
- Search for [#] to get to question number # quickly.
-
- ----------------------------------------------------------------
- [2-1] Is there a GNU-Emacs interface to Lisp?
-
- ILISP is a powerful GNU-Emacs interface to many dialects of
- Lisp, including Lucid, Allegro, {A}KCL, IBCL, and CMU. Written by
- Chris McConnell <ccm+@cs.cmu.edu>. It is available by anonymous
- ftp from katmandu.mt.cs.cmu.edu [128.2.250.68] in the directory
- pub/ilisp as the file ilisp.tar.Z. If you start using it, send
- Chris mail, as he maintains a mailing list of users.
-
- Franz Inc.'s GNU-Emacs/Lisp interface includes an online Common
- Lisp manual. It is available by license from Franz Inc. Contact
- info@franz.com for more information. There is also a mailing list,
- lisp-emacs-forum-request@ucbarpa.berkeley.edu.
-
- The cl-shell package provides a major mode (cl-shell-mode) for running
- Common Lisp (CL) as an Emacs subprocess. It provides a general
- mechanism for communication between CL and Emacs which does not rely
- on extra processes, and should therefore be easily portable to any
- version of CL. Features include direct (i.e., not through a temp file)
- evaluation and in-package compilation of forms from lisp-mode buffers,
- type-ahead and a history mechanism for the cl-shell buffer, and pop-up
- help facilities for the CL functions documentation, macroexpand and
- describe. Extensions for Lucid Common Lisp provide pop-up arglists
- and source file editing. Other extensions are provided to allow
- editing source files of CLOS or Flavors methods. Cl-shell is
- available on the Lucid tape (in the goodies directory) or via
- anonymous ftp from whitechapel.media.mit.edu (18.85.0.125).
-
- Lucid includes some other Emacs-Lisp interfaces in its goodies directory.
-
- Harlequin's LispWorks includes an Emacs-Lisp interface.
-
- Venue's Medley has an optional EMACS Interface.
-
- GNU-Emacs itself is available by anonymous ftp from prep.ai.mit.edu.
-
- ----------------------------------------------------------------
- [2-3] What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
-
- Hopefully, the only reason you need to do this is as part of trying to port
- some old MacLisp code to Common Lisp. These functions predated the
- inclusion of strings as a first-class data type in Lisp; symbols were used
- as strings, and they ere EXPLODEd to allow the individual characters to be
- manipulated in a list.
-
- Probably the best approximations of these are:
-
- (defun explode (object)
- (loop for char across (prin1-to-string object)
- collect (intern (string char))))
-
- (defun implode (list)
- (read-from-string (coerce (mapcar #'character list) 'string)))
-
- An alternate definition of EXPLODE which uses MAP instead of LOOP is:
-
- (defun explode (object)
- (map 'list #'(lambda (char)
- (intern (string char)))
- (prin1-to-string object)))
-
- The creation of N conses of garbage to process a string of N
- characters is a hideously inefficient way of doing the job. Rewrite
- EXPLODE code with PRIN1-TO-STRING, or better STRING if the arguments
- are symbols without funny characters. For IMPLODE, try to make its
- caller use strings and try to make the result usable as a string to
- avoid having to call INTERN or READ-FROM-STRING.
-
- ----------------------------------------------------------------
- [2-4] Is Lisp inherently slower than more conventional languages such as C?
-
- This is a tough question to answer, as I'm sure you expected. In many
- cases, it appears to be. Lisp does not require the programmer to specify
- the data type of variables, so generic arithmetic operators may have to
- perform type checking at runtime in order to determine how to proceed.
- However, Lisp code can also be denser (i.e. there is more expressed in a
- single line) than many other languages: the Lisp expression (+ A B) is more
- powerful than the C expression A+B (the Lisp version supports bignums,
- rationals, and complex numbers, while the C version only supports
- limited-size integers and floating point); therefore, one may claim that it
- is reasonable that the Lisp version take longer than the C version (but
- don't expect everyone to accept this rationalization). Solutions to this
- include hardware support (e.g. processors that support type tags in data,
- such as SPARC and Symbolics Lisp Machines), declarations, and specialized
- variants of functions (e.g. in MacLisp, + accepts and returns only fixnums,
- +$ accepts and returns only flonums, and PLUS is generic).
-
- At one time, the MIT PDP-10 MacLisp compiler was compared to DEC's PDP-10
- Fortran compiler. When appropriate declarations were supplied in the Lisp
- code, the performance of compiled Lisp arithmetic rivaled that of the
- Fortran code. It would hardly be fair to compare Lisp without declarations
- to Fortran, since the Fortran compiler would have more information upon
- which it could base its optimizations.
-
- Since Lisp is a good language for rapid prototyping, it is easy for a
- mediocre programmer (or even a good programmer, who isn't being careful) to
- generate a large amount of inefficient Lisp code. A good example is the use
- of APPEND to link successive lists together, instead of keeping a pointer
- to the tail of the list. Often a programmer can obtain significant
- speed increases by using a time/space profiler to identify the
- functions which waste time (often small functions which are called
- frequently) and rewriting those functions.
-
- ----------------------------------------------------------------
- [2-5] Why does Common Lisp have "#'"?
-
- #' is a macro-character which expands #'FOO to (FUNCTION FOO). Symbols in
- Lisp have two bindings, one for values and one for functions, allowing them
- to represent both variables and functions, depending on context. #'FOO
- accesses FOO's lexical function binding in a context where the value
- interpretation would normally occur. #' is also used to create lexical
- closures for lambda expressions. A lexical closure is a function which when
- invoked executes the body of the lambda-expression in the lexical
- environment within which the closure was created. See pp. 115-117 of CLtL2
- for more details.
-
- ----------------------------------------------------------------
- [2-6] How do I call non-Lisp functions from Lisp?
-
- Most Lisp implementations for systems where Lisp is not the most common
- language provide a "foreign function" interface. As of now there has been
- no significant standardization effort in this area. They tend to be
- similar, but there are enough differences that it would be inappropriate to
- try to describe them all here. In general, one uses an
- implementation-dependent macro that defines a Lisp function, but instead of
- supplying a body for the function, one supplies the name of a function written
- in another language; the argument list portion of the definition is
- generally augmented with the data types the foreign function expects and
- the data type of the foreign function's return value, and the Lisp
- interface function arranges to do any necessary conversions. There is also
- generally a function to "load" an object file or library compiled in a
- foreign language, which dynamically links the functions in the file being
- loaded into the address space of the Lisp process, and connects the
- interface functions to the corresponding foreign functions.
-
- If you need to do this, see the manual for your language implementation for
- full details. In particular, be on the lookout for restrictions on the
- data types that may be passed. You may also need to know details about the
- linkage conventions that are used on your system; for instance, many C
- implementations prepend an underscore onto the names of C functions when
- generating the assembler output (this allows them to use names without
- initial underscores internally as labels without worrying about conflicts),
- and the foreign function interface may require you to specify this form
- explicitly.
-
- Franz Allegro Common Lisp's "Foreign Function Call Facility" is
- described in chapter 10 of the documentation. Calling Lisp Functions
- from C is treated in section 10.8.2. The foreign function interface in
- Macintosh Common Lisp is similar. The foreign function interface for
- KCL is described in chapter 10 of the KCL Report. The foreign function
- interfaces for Lucid on the Vax and Lucid on the Sun4 are
- incompatible. Lucid's interface is described in chapter 5 of the
- Advanced User's Guide.
-
- ----------------------------------------------------------------
- [2-7] Can I call Lisp functions from other languages?
-
- In implementations that provide a foreign function interface as described
- above, there is also usually a "callback" mechanism. The programmer may
- associate a foreign language function name with a Lisp function. When a
- foreign object file or library is loaded into the Lisp address space, it is
- linked with these callback functions. As with foreign functions, the
- programmer must supply the argument and result data types so that Lisp may
- perform conversions at the interface. Note that in such foreign function
- interfaces Lisp is often left "in control" of things like memory
- allocation, I/O channels, and startup code (this is a major nuisance
- for lots of people).
-
- ----------------------------------------------------------------
-
- [2-8] I want to call a function in a package that might not exist at
- compile time. How do I do this?
-
- Use (funcall (find-symbol "SYMBOL-NAME" :pkg-name) ...).
-
- ----------------------------------------------------------------
- [2-9] What is CDR-coding?
-
- CDR-coding is a space-saving way to store lists in memory. It is normally
- only used in Lisp implementations that run on processors that are
- specialized for Lisp, as it is difficult to implement efficiently
- in software. In normal list structure, each element of the
- list is represented as a CONS cell, which is basically two pointers (the
- CAR and CDR); the CAR points to the element of the list, while the CDR
- points to the next CONS cell in the list or NIL. CDR-coding takes
- advantage of the fact that most CDR cells point to another CONS, and
- further that the entire list is often allocated at once (e.g. by a call to
- LIST). Instead of using two pointers to implement each CONS cell, the CAR
- cell contains a pointer and a two-bit "CDR code". The CDR code may contain
- one of three values: CDR-NORMAL, CDR-NEXT, and CDR-NIL. If the code is
- CDR-NORMAL, this cell is the first half of an ordinary CONS cell pair, and
- the next cell in memory contains the CDR pointer as described above. If
- the CDR code is CDR-NEXT, the next cell in memory contains the next CAR
- cell; in other words, the CDR pointer is implicitly thisaddress+1, where
- thisaddress is the memory address of the CAR cell. If the CDR code is
- CDR-NIL, then this cell is the last element of the list; the CDR pointer is
- implicitly a reference to the object NIL. When a list is constructed
- incrementally using CONS, a chain of ordinary pairs is created; however,
- when a list is constructed in one step using LIST or MAKE-LIST, a block of
- memory can be allocated for all the CAR cells, and their CDR codes all set
- to CDR-NEXT (except the last, which is CDR-NIL), and the list will only
- take half as much storage (because all the CDR pointers are implicit).
-
- If this were all there were to it, it would not be difficult to implement
- in software on ordinary processors; it would add a small amount of overhead
- to the CDR function, but the reduction in paging might make up for it. The
- problem arises when a program uses RPLACD on a CONS cell that has a CDR
- code of CDR-NEXT or CDR-NIL. Normally RPLACD simply stores into the CDR
- cell of a CONS, but in this case there is no CDR cell -- its contents are
- implicitly specified by the CDR code, and the word that would normally
- contain the CDR pointer contains the next CONS cell (in the CDR-NEXT case)
- to which other data structures may have pointers, or the first word of some
- other object (in the CDR-NIL case). When CDR-coding is used, the
- implementation must also provide automatic "forwarding pointers"; an
- ordinary CONS cell is allocated, the CAR of the original cell is copied
- into its CAR, the value being RPLACD'ed is stored into its CDR, and the old
- CAR cell is replaced with a forwarding pointer to the new CONS cell.
- Whenever CAR or CDR is performed on a CONS, it must check whether the
- location contains a forwarding pointer. This overhead on both CAR and CDR,
- coupled with the overhead on CDR to check for CDR codes, is generally
- enough that using CDR codes on conventional hardware is infeasible.
-
- There is some evidence that CDR-coding doesn't really save very much
- memory, because most lists aren't constructed at once, or RPLACD is done on
- them enough that they don't stay contiguous. At best this technique can
- save 50% of the space occupied by CONS cells. However, the savings probably
- depends to some extent upon the amount of support the implementation
- provides for creating CDR-coded lists. For instance, many system functions
- on Symbolics Lisp Machines that operate on lists have a :LOCALIZE option;
- when :LOCALIZE T is specified, the list is first modified and then copied
- to a new, CDR-coded block, with all the old cells replaced with forwarding
- pointers. The next time the garbage collector runs, all the forwarding
- pointers will be spliced out. Thus, at a cost of a temporary increase in
- memory usage, overall memory usage is generally reduced because more lists
- may be CDR-coded. There may also be some benefit in improved paging
- performance due to increased locality as well (putting a list into
- CDR-coded form makes all the "cells" contiguous). Nevertheless, modern
- Lisps tend to use lists much less frequently, with a much heavier
- reliance upon code, strings, and vectors (structures).
-
- ----------------------------------------------------------------
- [2-10] What is garbage collection?
-
- Garbage Collection (GC) refers to the automatic storage allocation
- mechanisms present in many Lisps. There are several kinds of storage
- allocation algorithms, but most fall within two main classes:
-
- 1. Stop and Copy. Systems which copy active objects from "old"
- storage to "new" storage and then recycle the old storage.
-
- 2. Mark and Sweep. Systems which link together storage
- used by discarded objects.
-
- Generational scavenging garbage collection (aka emphemeral GC) is a
- variation in which memory is allocated in layers, with tenured
- (long-lived) objects in the older layers. Rather than doing a full GC
- of all of memory every time more room is needed, only the last few
- layers are GCed during an ephemeral GC, taking much less time.
- Short-lived objects are quickly recycled, and full GCs are then much
- less frequent. It is most often used to improve the performance of
- stop and copy garbage collectors. It is possible to implement
- ephemeral GC in mark and sweep systems, just much more difficult.
-
- Stop and copy garbage collection provides simpler storage allocation,
- avoids fragmentation of memory (intermixing of free storage with used
- storage). Copying, however, consumes more of the address space, since up to
- half the space must be kept available for copying all the active objects.
- This makes stop and copy GC impractical for systems with a small address
- space or without virtual memory. Also, copying an object requires that you
- track down all the pointers to an object and update them to reflect the new
- address, while in a non-copying system you need only keep one pointer to an
- object, since its location will not change. It is also more difficult to
- explicitly return storage to free space in a copying system.
-
- Garbage collection is not part of the Common Lisp standard. Most Lisps
- provide a function ROOM which provides human-readable information about the
- state of storage usage. In many Lisps, (gc) invokes an ephemeral garbage
- collection, and (gc t) a full garbage collection.
-
- ----------------------------------------------------------------
- [2-11] How do I save an executable image of my loaded Lisp system?
- How do I run a Unix command in my Lisp?
- How do I get the current directory name from within a Lisp program?
-
- There is no standard for dumping a Lisp image. Here are the
- commands from some lisp implementations:
- Lucid: DISKSAVE
- Symbolics: Save World [CP command]
- CMU CL: SAVE-LISP
- Franz Allegro: EXCL:DUMPLISP (documented)
- SAVE-IMAGE (undocumented)
- Medley: IL:SYSOUT or IL:MAKESYS
- MCL: SAVE-APPLICATION <pathname>
- &key :toplevel-function :creator :excise-compiler
- :size :resources :init-file :clear-clos-caches
- KCL: (si:save-system "saved_kcl")
-
- There is no standard for running a Unix shell command from Lisp,
- especially since not all Lisps run on top of Unix. Here are the
- commands from some Lisp implementations:
- Allegro: EXCL:RUN-SHELL-COMMAND
- Lucid: RUN-PROGRAM (name
- &key input output
- error-output (wait t) arguments
- (if-input-does-not-exist :error)
- (if-output-exists :error)
- (if-error-output-exists :error))
- KCL: SYSTEM
- For example, (system "ls -l").
- You can also try RUN-PROCESS and EXCLP, but they
- don't work with all versions of KCL.
-
- There's no standard function for finding the current directory from
- within a Lisp program, since not all Lisp environments have the
- concept of a current directory. Here are the commands from some Lisp
- implementations:
- Lucid: working-directory (which is also SETFable)
- pwd and cd also work
- Allegro: current-directory (use excl:chdir to change it)
- CMU CL: default-directory
-
- Allegro also uses the variable *default-pathname-defaults* to resolve
- relative pathnames, maintaining it as the current working directory.
- So evaluating (truename "./") in Allegro (and on certain other
- systems) will return a pathname for the current directory. Likewise,
- in some VMS systems evaluating (truename "[]") will return a pathname
- for the current directory.
-
- ----------------------------------------------------------------
- [2-12] I'm porting some code from a Symbolics Lisp machine to some
- other platform, and there are strange characters in the code.
- What do they mean?
-
- The Symbolics Zetalisp character set includes the following
- characters not present in other Lisps:
- ^] >= greater than or equal to
- ^\ <= less than or equal to
- ^Z != not equal to
- ^^ == equivalent to
- ^E not
- ^G pi
- ^L +/- plus/minus
- ^H lambda
- ^F epsilon
- ^W <--> left/right arrow
- ^X <-- left arrow
- ^Y --> right arrow
-
- Other special characters to look out for are the font-change characters,
- which are represented as a ^F followed by a digit or asterisk. A digit
- means to push font #N onto the stack; an asterisk means to pop the most
- recent font from the stack. You can clean up the code by replacing "\^F."
- with "".
-
- ----------------------------------------------------------------
- [2-13] History: Where did Lisp come from?
-
- John McCarthy developed the basics behind Lisp during the 1956 Dartmouth
- Summer Research Project on Artificial Intelligence. He intended it as an
- algebraic LISt Processing (hence the name) language for artificial
- intelligence work. Early implementations included the IBM 704, the IBM
- 7090, the DEC PDP-1, the DEC PDP-6 and the DEC PDP-10. The PDP-6 and
- PDP-10 had 18-bit addresses and 36-bit words, allowing a CONS cell to
- be stored in one word, with single instructions to extract the CAR and
- CDR parts. The early PDP machines had a small address space, which
- limited the size of Lisp programs.
-
- Milestones in the development of Lisp:
-
- 1956 Dartmouth Summer Research Project on AI.
-
- 1960-65 Lisp1.5 is the primary dialect of Lisp.
-
- 1964- Development of BBNLisp at BBN.
-
- late 60s Lisp1.5 diverges into two main dialects:
- Interlisp (originally BBNLisp) and MacLisp.
-
- early 70s Development of special-purpose computers known as Lisp
- Machines, designed specificly to run Lisp programs.
- Xerox D-series Lisp Machines run Interlisp-D.
- Early MIT Lisp Machines run Lisp Machine Lisp
- (an extension of MacLisp).
-
- 1969 Anthony Hearn and Martin Griss define Standard Lisp to
- port REDUCE, a symbolic algebra system, to a variety
- of architectures.
-
- late 70s Macsyma group at MIT developed NIL (New Implementation
- of Lisp), a Lisp for the VAX.
-
- Stanford and Lawrence Livermore National Laboratory
- develop S-1 Lisp for the Mark IIA supercomputer.
-
- Franz Lisp (dialect of MacLisp) runs on stock-hardware
- Unix machines.
-
- Gerald J. Sussman and Guy L. Steele developed Scheme,
- a simple dialect of Lisp with lexical scoping and
- lexical closures, continuations as first-class objects,
- and a simplified syntax (i.e., only one binding per symbol).
-
- Advent of object-oriented programming concepts in Lisp.
- Flavors was developed at MIT for the Lisp machine,
- and LOOPS (Lisp Object Oriented Programming System) was
- developed at Xerox.
-
- early 80s Development of SPICE-Lisp at CMU, a dialect of MacLisp
- designed to run on the Scientific Personal Integrated
- Computing Environment (SPICE) workstation.
-
- 1980 First biannual ACM Lisp and Functional Programming Conf.
-
- 1981 PSL (Portable Standard Lisp) runs on a variety of platforms.
-
- 1981+ Lisp Machines from Xerox, LMI (Lisp Machines Inc)
- and Symbolics available commercially.
-
- April 1981 Grass roots definition of Common Lisp as a description
- of the common aspects of the family of languages (Lisp
- Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, Scheme).
-
-
- 1984 Publication of CLtL1. Common Lisp becomes a de facto
- standard.
-
- 1986 X3J13 forms to produce a draft for an ANSI Common Lisp
- standard.
-
- 1987 Lisp Pointers commences publication.
-
- 1990 Steele publishes CLtL2 which offers a snapshot of
- work in progress by X3J13. (Unlike CLtL1, CLtL2
- was NOT an output of the standards process and was
- not intended to become a de facto standard. Read
- the Second Edition Preface for further explanation
- of this important issue.) Includes CLOS,
- conditions, pretty printing and iteration facilities.
-
- 1992 X3J13 creates a draft proposed American National
- Standard for Common Lisp. This document is the
- first official successor to CLtL1.
-
- [Note: This summary is based primarily upon the History section of the
- draft ANSI specification. More detail and references can be obtained from
- that document. See [1-5] for information on obtaining a copy.]
- ----------------------------------------------------------------
- [2-14] How do I find the argument list of a function?
- How do I get the function name from a function object?
-
- There is no standard way to find the argument list of a function,
- since implementations are not required to save this information.
- However, many implementations do remember argument information, and
- usually have a function that returns the lambda list. Here are the
- commands from some Lisp implementations:
-
- Lucid: arglist
- Allegro: excl::arglist
- Symbolics: arglist
-
- CMU Common Lisp, new compiler:
- #+(and :CMU :new-compiler)
- (defun arglist (name)
- (let* ((function (symbol-function name))
- (stype (system:%primitive get-vector-subtype function)))
- (when (eql stype system:%function-entry-subtype)
- (cadr (system:%primitive header-ref function
- system:%function-entry-type-slot)))))
-
- If you're interested in the number of required arguments you could use
-
- (defun required-arguments (name)
- (or (position-if #'(lambda (x) (member x lambda-list-keywords))
- (arglist name))
- (length (arglist name))))
-
- To extract the function name from the function object, as in
- (function-name #'car) ==> 'car
- use the following vendor-dependent functions:
-
- Symbolics: (si::compiled-function-name <fn>)
- Lucid: (sys::procedure-ref <fn> SYS:PROCEDURE-SYMBOL)
- Allegro: (Xref::object-to-function-name <fn>)
- CMU CL: (kernel:%function-header-name <fn>)
- AKCL: (system::compiled-function-name <fn>)
- MCL: (ccl::function-name <fn>)
-
- ----------------------------------------------------------------
- [2-15] How can I have two Lisp processes communicate via unix sockets?
-
- CLX uses Unix sockets to communicate with the X window server. Look at
- the following files from the CLX distribution for a good example of
- using Unix sockets from Lisp:
- defsystem.lisp Lucid, AKCL, IBCL, CMU.
- socket.c, sockcl.lisp AKCL, IBCL
- excldep.lisp Franz Allegro CL
- You will need the "socket.o" files which come with Lucid and Allegro.
- To obtain CLX, see the entry for CLX in the answer to question [6-5].
-
- See the file lisp-sockets.text in the Lisp Utilities repository
- described in the answer to question [6-1].
-
- ----------------------------------------------------------------
-
- ;;; *EOF*
-